com2H gdb stub should communicate on com2 (with high bit set)
Symbolic debugging infomration is quite helpful too:
- xeno.bk/xen/arch/i386/Rules.mk
+ xeno.bk/xen/arch/x86/Rules.mk
add -g to CFLAGS to compile Xen with symbols
- xeno.bk/xenolinux-2.4.24-sparse/arch/xen/Makefile
+ xeno.bk/linux-2.4.27-xen-sparse/arch/xen/Makefile
add -g to CFLAGS to compile Linux with symbols
You may also want to consider dedicating a register to the
frame pointer (disable the -fomit-frame-pointer compile flag).
When booting Xen and domain 0, look for the console text
- "Initializing pervasive debugger (PDB)" just before DOM0 starts up.
+ "pdb: pervasive debugger" just before DOM0 starts up.
Serial Port Configuration
(gdb) delete
Delete all breakpoints? (y or n) y
4. You can add additional symbols to gdb
- (gdb) add-sym xenolinux-2.4.24/vmlinux
- add symbol table from file "xenolinux-2.4.24/vmlinux" at
+ (gdb) add-sym xeno.bk/linux-2.4.27-xen0/vmlinux
+ add symbol table from file "xeno.bk/linux-2.4.27-xen0/vmlinux" at
(y or n) y
- Reading symbols from xenolinux-2.4.24/vmlinux...done.
+ Reading symbols from xeno.bk/linux-2.4.27-xen0/vmlinux...done.
(gdb) x/s cpu_vendor_names[0]
0xc01530d2 <cpdext+62898>: "Intel"
(gdb) break free_uid
define setup
file xeno-clone/xeno.bk/xen/xen
- add-sym xeno-clone/xenolinux-2.4.25/vmlinux
+ add-sym xeno-clone/xeno.bk/linux-2.4.27-xen0/vmlinux
add-sym ~ach61/a.out
end
define setup
file .../install/boot/xen-syms
- add-sym .../install/boot/vmlinux-syms-2.4.26-xen0
+ add-sym .../install/boot/vmlinux-syms-2.4.27-xen0
add-sym /homes/aho/a.out
end
document setup
{\tt http://www.cl.cam.ac.uk/netos/papers/2003-xensosp.pdf}\\
Work to port Xen to x86\_64 and IA64 is currently underway.
-Xen is targetted at server-class machines, and the current list of
+Xen is targeted at server-class machines, and the current list of
supported hardware very much reflects this, avoiding the need for us
to write drivers for "legacy" hardware. It is likely that some desktop
chipsets will fail to work properly with the default Xen
that we should be compatible with the majority of device hardware
supported by Linux. The default XenLinux build contains support for
relatively modern server-class network and disk hardware, but you can
-add suppport for other hardware by configuring your XenLinux kernel in
+add support for other hardware by configuring your XenLinux kernel in
the normal way (e.g. \verb_# make ARCH=xen xconfig_).
\section{History}
scenarios on multiple sites.
Xen 2.0 is the latest release, featuring greatly enhanced hardware
-support, configuration flexibility, useability and a larger complement
+support, configuration flexibility, usability and a larger complement
of supported operating systems. We think that Xen has the potential
to become {\em the} definitive open source virtualisation solution and
will work to conclusively achieve that position.
\item[\path{tools/}] Xen node controller daemon (Xend), command line tools,
control libraries
\item[\path{xen/}] The Xen hypervisor itself.
-\item[\path{linux-2.4.26-xen/}] Linux 2.4 support for Xen
+\item[\path{linux-2.4.27-xen/}] Linux 2.4 support for Xen
\item[\path{linux-2.6.7-xen/}] Linux 2.6 support for Xen
\item[\path{doc/}] various documentation files for users and developers
\item[\path{extras/}] currently this contains the Mini OS, aimed at developers
which it will then add the Xen architecture files to. You can tell the
makefile the location of the appropriate linux compressed tar file by
setting the LINUX\_SRC environment variable, e.g. \\
-\verb!# LINUX_SRC=/tmp/linux-2.4.26.tar.gz make world! \\ or by
+\verb!# LINUX_SRC=/tmp/linux-2.4.27.tar.gz make world! \\ or by
placing the tar file somewhere in the search path of {\tt LINUX\_SRC\_PATH}
which defaults to ``{\tt .:..}". If the makefile can't find a suitable
kernel tar file it attempts to download it from kernel.org (this won't
Take a look at the files in \path{install/boot/}:
\begin{itemize}
\item \path{install/boot/xen.gz} The Xen 'kernel'
-\item \path{install/boot/vmlinuz-2.4.26-xen0} Domain 0 XenLinux kernel
-\item \path{install/boot/vmlinuz-2.4.26-xenU} Unprivileged XenLinux kernel
+\item \path{install/boot/vmlinuz-2.4.27-xen0} Domain 0 XenLinux kernel
+\item \path{install/boot/vmlinuz-2.4.27-xenU} Unprivileged XenLinux kernel
\end{itemize}
The difference between the two Linux kernels that are built is due to
The \path{install/boot} directory will also contain the config files
used for building the XenLinux kernels, and also versions of Xen and
XenLinux kernels that contain debug symbols (\path{xen-syms} and
-\path{vmlinux-syms-2.4.26-xen0}) which are essential for interpreting crash
+\path{vmlinux-syms-2.4.27-xen0}) which are essential for interpreting crash
dumps. Retain these files as the developers may wish to see them if
you post on the mailing list.
distribution. The entry should look something like the following:
\begin{verbatim}
-title Xen 2.0 / XenoLinux 2.4.26
+title Xen 2.0 / XenLinux 2.4.27
kernel /boot/xen.gz dom0_mem=131072 com1=115200,8n1
- module /boot/xenolinux.gz root=/dev/sda4 ro console=tty0 console=ttyS0
+ module /boot/vmlinuz-2.4.27-xen0 root=/dev/sda4 ro console=tty0 console=ttyS0
\end{verbatim}
The first line of the configuration (kernel...) tells GRUB where to
find Xen itself and what boot parameters should be passed to it. The
second line of the configuration describes the location of the
-XenoLinux kernel that Xen should start and the parameters that should
+XenLinux kernel that Xen should start and the parameters that should
be passed to it.
As always when installing a new kernel, it is recommended that you do
\begin{description}
\item[kernel] Set this to the path of the kernel you compiled for use
with Xen. [e.g. {\tt kernel =
- '/root/xeno-unstable.bk/install/boot/vmlinuz-2.4.26-xenU'}]
+ '/root/xeno-unstable.bk/install/boot/vmlinuz-2.4.27-xenU'}]
\item[memory] Set this to the size of the domain's memory in
megabytes. [e.g. {\tt memory = 64 } ]
\item[disk] Set the first entry in this list to calculate the offset
Choose a free loop back device, and attach file: \\
\verb_# losetup /dev/loop0 vm1disk_ \\
Make a file system on the loop back device: \\
-\verb_# mkfs t ext3 /dev/loop0_
+\verb_# mkfs -t ext3 /dev/loop0_
Populate the file system e.g. by copying from the current root:
\begin{verbatim}
\item[nics] Number of virtual network interfaces.
\item[vif] List of MAC addresses (random addresses are assigned if not given).
\item[disk] Regions of disk to export to the domain.
-\item[dhcp] Set to {\tt 'dhcp'} if you want to DHCP allocate the IP addres.
+\item[dhcp] Set to {\tt 'dhcp'} if you want to DHCP allocate the IP address.
\item[netmask] IP netmask.
\item[gateway] IP address for the gateway (if any).
\item[hostname] Set the hostname for the virtual machine.
of the CPU, with timeliness guarantees and a
mechanism for sharing out ``slack time''.
-\item[BVT] The BVT scheduler is used to give propotional
+\item[BVT] The BVT scheduler is used to give proportional
fair shares of the CPU to domains.
\item[Exokernel] A minimal piece of privileged code, similar to
the system.
\item[Domain ID] A unique identifier for a { \bf domain },
- analagous to a process ID in an operating
+ analogous to a process ID in an operating
system. Apart from domain
\item[Full virtualisation] An approach to virtualisation which
Xen offers a boot time choice between multiple schedulers. To select
a scheduler, pass the boot parameter { \tt sched=sched\_name } to Xen,
-substituting the apropriate scheduler name. Details of the schedulers
-and their parameters are included below; future verions of the tools
+substituting the appropriate scheduler name. Details of the schedulers
+and their parameters are included below; future versions of the tools
will provide a higher-level interface to these tools.
\section{Borrowed Virtual Time}
These options are used to configure Xen's behaviour at runtime. They
should be appended to Xen's command line, either manually or by
-editting \path{grub.conf}.
+editing \path{grub.conf}.
\section{List of options}
have MSB cleared.
\end{description}
The latter two examples allow a single port to be
- shared by two subsystems (eg. console and
+ shared by two subsystems (e.g. console and
debugger). Sharing is controlled by MSB of each
transmitted/received character.
[NB. Default for this option is 'com1,tty'] \\
list increases, a dedicated user support list may be introduced.
\end{document}
+
projects / xen.git / commitdiff